Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / security / tcp_wrapper.txt < prev next >

Wrap

Text File | 1992-08-31 | 24.3 KB | 727 lines

TCP WRAPPER Network monitoring, access control, and booby traps. Wietse Venema Mathematics and Computing Science Eindhoven University of Technology The Netherlands wietse@wzv.win.tue.nl Abstract This paper presents a simple tool to monitor and control incoming network traffic. The tool has been successfully used for shielding off systems and for detection of cracker activity. It has no impact on legal computer users, and does not require any change to existing systems software or con- figuration files. The tool has been installed world-wide on numerous UNIX systems without any source code change. 1. Our pet. The story begins about two years ago. Our university was under heavy attack by a Dutch computer cracker who again and again managed to acquire root privilege. That alone would have been nothing more than an annoyance, but this indivi- dual was very skilled at typing the following command sequence: rm -rf / For those with no UNIX experience: this command, when exe- cuted at a sufficiently high privilege level (like root), is about as destructive as the MS-DOS format command. Usually, the damage could be repaired from backup tapes, but every now and then people still lost a large amount of work. Though we did have very strong indications about the cracker's identity I cannot disclose his name. We did give him a nickname, though: "our pet"1. _________________________ 1. Like hond (dog), kat (cat), and muis (mouse). July 15, 1992 - 2 - 2. The cracker is watching us. The destructive behavior of the cracker made it very hard to find out what was going on: the rm -rf removed all traces very effectively. One late night I noticed that the cracker was watching us over the network. He did this by frequently making contact with our finger network service, which gives information about users. Services such as finger do not require a password, and almost never keep a record of their use. That explains why all his fingering activity had remained unnoticed. The natural reaction would be to shut down the finger net- work service. I decided, however, that it would be more productive to maintain the service and to find out where the finger requests were coming from. 3. A typical UNIX TCP/IP networking implementation. In order to explain the problem and its solution I will briefly summarize a typical UNIX implementation of the TCP/IP network services. Experts will forgive me when I make a few simplifications. Almost every application of the TCP/IP protocols is based on a client-server model. For example, when someone uses the telnet command to connect to a host, a telnet server process is started on the target host. The server process connects the user to a login process. A few examples are shown in table 1. client server application ________________________________ telnet telnetd remote login ftp ftpd file transfer finger fingerd show users systat systatd show users Table 1. Examples of TCP/IP client-server pairs and their applications. The usual approach is to run one daemon process that waits for all kinds of incoming network connections. Whenever a connection is established this daemon (usually called inetd) runs the appropriate server program and goes back to sleep, waiting for other connections. 4. The "tcp wrapper" trick. Back to the original problem: how to get the name of the host that the cracker was spying from. At first sight, this would require changes to existing network software. There were a few problems, though: July 15, 1992 - 3 - --------- ----------------- (ftp)-----| i | user---| telnet client |----(telnet)--| n | ----------------- . | e | . | t | (finger)--| d | --------- Figure 1. The inetd daemon process listens on the ftp, telnet etc. network ports and waits for incoming con- nections. The figure shows that a user has connected to the telnet port. ----------------- ----------------- --------- user---| telnet client |------| telnet server |----| login | ----------------- ----------------- --------- Figure 2. The inetd process has started a telnet server process that connects the user to a login pro- cess. Meanwhile, inetd waits for other incoming con- nections. o We did not have a source license for the Ultrix, SunOS and other UNIX implementations on our systems. And no, we did not have those sources either. o The Berkeley network sources (from which most of the commercial UNIX TCP/IP network implementations are derived) were available, but porting these to our environments would require an unknown amount of work. Fortunately, there was a simple solution that did not require any change to existing software, and that turned out to work on all UNIX systems that I tried it on. The trick was to make a swap: move the vendor-provided network server programs to another place, and install a trivial program in the original place of the network server programs. Whenever a connection was made, the trivial program would just record the name of the remote host, and then run the original net- work server program. ----------------- ----------------- user---| telnet client |------| tcp wrapper |---> logfile ----------------- ----------------- Figure 3. The original telnet server program has been moved to some other place, and the tcp wrapper has tak- en its place. The wrapper logs the name of the remote host to a file. July 15, 1992 - 4 - ----------------- ----------------- --------- user---| telnet client |------| telnet server |----| login | ----------------- ----------------- --------- Figure 4. The tcp wrapper program has started the real telnet server and no longer participates. The user can- not notice any difference. The first tcp wrapper version was just a few lines of code that I had carefully copied from some old network daemon source. Because it did not exchange any information with the client or server processes, the same tcp wrapper version could be used for many types of network service. Although I could install the wrapper only on a dozen systems it was an immediate success. Figure 5 gives an early exam- ple. May 21 14:06:53 tuegate: systatd: connect from monk.rutgers.edu May 21 16:08:45 tuegate: systatd: connect from monk.rutgers.edu May 21 16:13:58 trf.urc: systatd: connect from monk.rutgers.edu May 21 18:38:17 tuegate: systatd: connect from ap1.eeb.ele.tue.nl May 21 23:41:12 tuegate: systatd: connect from mcl2.utcs.utoronto.ca May 21 23:48:14 tuegate: systatd: connect from monk.rutgers.edu May 22 01:08:28 tuegate: systatd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:14:46 tuewsd: fingerd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:15:32 tuewso: fingerd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:55:46 tuegate: systatd: connect from monk.rutgers.edu May 22 01:58:33 tuegate: systatd: connect from monk.rutgers.edu May 22 02:00:14 tuewsd: fingerd: connect from monk.rutgers.edu May 22 02:14:51 tuegate: systatd: connect from RICHARKF-TCACCIS.ARMY.MIL May 22 02:19:45 tuewsd: fingerd: connect from RICHARKF-TCACCIS.ARMY.MIL May 22 02:20:24 tuewso: fingerd: connect from RICHARKF-TCACCIS.ARMY.MIL May 22 14:43:29 tuegate: systatd: connect from monk.rutgers.edu May 22 15:08:30 tuegate: systatd: connect from monk.rutgers.edu May 22 15:09:19 tuewse: fingerd: connect from monk.rutgers.edu May 22 15:14:27 tuegate: telnetd: connect from cumbic.bmb.columbia.edu May 22 15:23:06 tuegate: systatd: connect from cumbic.bmb.columbia.edu May 22 15:23:56 tuewse: fingerd: connect from cumbic.bmb.columbia.edu Figure 5. Some of the first cracker connections ob- served with the tcp wrapper program. Each connection is recorded with: time stamp, the name of the local host, the name of the requested service (actually, the net- work server process name), and the name of the remote host. The examples show that the cracker not only used dial-up terminal servers (such as monk.rutgers.edu), but also that he had broken into military (.MIL) and university (.EDU) computer systems. July 15, 1992 - 5 - The cracker literally bombarded our systems with finger and systat requests. These allowed him to see who was on our systems. Every now and then he would make a telnet connec- tion, presumably to make a single login attempt and to disconnect immediately, so that no "repeated login failure" would be reported to the systems console. Thus, while the cracker thought he was spying on us we could from now on see where he was. This was a major improvement over the past, when we only knew something had happened after he had performed his rm -rf act. My initial fear was that we would be swamped by logfile information and that there would be too much noise to find the desired signal. Fortunately, the cracker was easy to recognize: o He often worked at night, when there is little other activity. o He would often make a series of connections to a number of our systems. By spreading his probes he perhaps hoped to hide his activities. However, by merging the logs from several systems it was actually easier to see when the cracker was in the air. o No-one else used the systat service. In the above example, one of the systat connections came from a system within our university: ap1.eeb.ele.tue.nl, member of a ring of Apollo workstations. Attempts to alert their system administrator were in vain: one week later all their file systems were wiped out. The backups were between one and two years old, so the damage was extensive. 5. First extension: access control. I will not go into a discussion on the pros and cons of publicly-accessible terminal servers with world-wide inter- net access, but it is clear that any traces that originated from such a system would be useless for our purposes: we would need cooperation from US and Dutch telephone com- panies, from the administrators of those terminal servers, and so on. The best thing to do was to refuse connections from open terminal servers, so that the cracker could reach us only after breaking into a regular user account. Our hope was that the would leave some useful traces, so that we would get to know him a little better. I built a simple access-control mechanism into the tcp wrapper. Whenever a connection from a terminal server showed up in the logs, all traffic from that system would be July 15, 1992 - 6 - blocked on our side, and we would ask the responsible administrators to do the same on their side. Sometimes it even worked. Figure 6 gives a snapshot of our access- control files. /etc/hosts.allow: in.ftpd: ALL /etc/hosts.deny: ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu ALL: comserv.princeton.edu lewis-sri-gw.army.mil ALL: ruut.cc.ruu.nl 131.211.112.44 ALL: tip-gsbi.stanford.edu ALL: tip-quada.stanford.edu ALL: s101-x25.stanford.edu ALL: tip-cdr.stanford.edu ALL: tip-cromemaa.stanford.edu ALL: tip-cromembb.stanford.edu ALL: tip-forsythe.stanford.edu Figure 6. Sample access-control files. The first file describes which (service, host) combinations are al- lowed. In this example, the ftp file transfer service is granted to all systems. The second file describes which of the remaining (ser- vice, host) combinations are disallowed. In this exam- ple, an ever-growing list of open terminal servers is refused access. (service, host) pairs that are not matched by any of the access-control files are always allowed. 6. Our turn: watching the cracker. Now that the cracker could no longer attack us from publicly-accessible terminal servers, all he could do was to break into a regular user account and proceed from there. That is exactly what he did. The next step was to find out what user accounts were involved. I quickly cobbled together something that would consult a table of "bad" sites and send a finger and systat probe whenever one made a connection to us. Now we would be able to watch the cracker just like he had been watching us. July 15, 1992 - 7 - During the next months I identified several broken-into accounts. Each time I would send a notice to the system administrators, and a copy to CERT2 to keep them informed of our progress. Jan 30 04:55:09 tuegate: telnetd: connect from guzzle.Stanford.EDU Jan 30 05:10:02 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:17:57 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:18:24 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:18:34 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:18:38 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:18:44 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:21:03 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:24:46 tuegate: systatd: connect from guzzle.Stanford.EDU Jan 30 05:27:20 svin01: fingerd: connect from gloworm.Stanford.EDU Jan 30 05:33:33 svin01: telnetd: connect from guzzle.Stanford.EDU Jan 30 05:33:38 svin01: telnetd: connect from guzzle.Stanford.EDU Jan 30 05:33:41 svin01: telnetd: connect from guzzle.Stanford.EDU Jan 30 05:33:50 svin01: ftpd: connect from guzzle.Stanford.EDU Jan 30 05:33:58 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:34:08 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:34:54 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:35:16 svin01: fingerd: connect from guzzle.Stanford.EDU Jan 30 05:35:36 svin01: fingerd: connect from guzzle.Stanford.EDU Figure 7. A burst of network activity, most of it from Stanford. Wed Jan 30 05:10:08 MET 1991 [guzzle.stanford.edu] Login name: adrian In real life: Adrian Cooper Directory: /u0/adrian Shell: /phys/bin/tcsh On since Jan 29 19:30:18 on ttyp0 from tip-forsythe.Sta No Plan. Figure 8. A reverse finger result, showing that only one user was logged on at the time. The examples in figures 7 and 8 show activity from a single user who was logged in on the system guzzle.Stanford.EDU. The account name is adrian, and the login came in via the terminal server tip-forsythe.Stanford.EDU. Because of that terminal server I wasn't too optimistic. Things turned out to be otherwise. _________________________ 2. Computer Emergency Response Team, an organization that was called into existence after the Internet worm in- cident in 1988. July 15, 1992 - 8 - CERT suggested that I contact Stephen Hansen of Stanford university. He had been monitoring the cracker for some time, and his logs gave an excellent insight into how the cracker operated. The cracker did not use any black magic: he knew many system software bugs, and was very persistent in his attempts to get superuser privilege. Getting into a system was just a matter of finding an account with a weak password. For several months the cracker used Stanford as his home base to attack a large number of sites. One of his targets was research.att.com, the AT&T Bell labs gateway. Bill Cheswick and colleagues even let him in, after setting up a well-protected environment where they could watch him. This episode is extensively described in [1]. Unfortunately, the cracker was never arrested. He should have waited just one year. Instead, the honor was given to two much less harmful Dutch youngsters, at the end of Febru- ary, 1992. 7. Second extension: booby traps. Automatic reverse fingers had proven useful, so I decided to integrate the "ad hoc" reverse finger tool with the tcp wrapper. To this end, the access-control language was extended so that arbitrary shell commands could be speci- fied. Now that the decision to execute shell commands was based on both the service and the host name, it became possible to automatically detect some types of "suspicious" traffic. For example: remote access to network services that should be accessed only from local systems. Over the past months I had noticed several tftp (trivial file transfer protocol) requests from far-away sites. This protocol does not require any password, and it is often used for downloading systems software to diskless workstations or to dedicated network hardware. Until a few years ago, the protocol could also be used to read any file on the system. For this reason, it is still popular with crackers. The access-control tables (fig. 9) were set up such that local tftp requests would be handled in the usual manner. Remote tftp requests, however, would be refused. Instead of the requested file, a finger probe would be sent to the offending host. The alarm goes off about once every two months. The action is as usual: send a message to CERT and to the site contact (never to the broken-into system). July 15, 1992 - 9 - /etc/hosts.allow: in.tftpd: LOCAL, .win.tue.nl /etc/hosts.deny: in.tftpd: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail wswietse Figure 9. Example of a booby trap on the tftp service. The entry in the first access-control file says that tftp connections from hosts within its own domain are allowed. The entry in the second file causes the tcp wrapper to perform a reverse finger in all other cases. The %h se- quence is replaced by the actual remote host name. The result is sent to me by electronic mail. This is an example of recent tftp activity: Jan 4 18:58:28 svin02 tftpd: refused connect from E40-008-8.MIT.EDU Jan 4 18:59:45 svin02 tftpd: refused connect from E40-008-8.MIT.EDU Jan 4 19:01:02 svin02 tftpd: refused connect from E40-008-8.MIT.EDU Jan 4 19:02:19 svin02 tftpd: refused connect from E40-008-8.MIT.EDU Jan 4 19:03:36 svin02 tftpd: refused connect from E40-008-8.MIT.EDU Jan 4 19:04:53 svin02 tftpd: refused connect from E40-008-8.MIT.EDU Due to the nature of the tftp protocol, the refused request was repeated every 77 seconds. The retry interval is imple- mentation dependent and can give some hints about the type of the remote system. According to the reverse finger results, only one person was active at that time: apparently, the login came from a sys- tem in France. Login name: mvscott In real life: Mark V Scott Office: 14S-134, x3-6724 Directory: /mit/mvscott Shell: /bin/csh On since Jan 4 12:46:44 on ttyp0 from cnam.cnam.fr 12 seconds Idle Time No Plan. France told me that the cracker came from a NASA terminal server (sdcds8.gsfc.nasa.gov): hyper1 ttyp3 sdcds8.gsfc.nasa Sat Jan 4 17:51 - 20:47 (02:55) July 15, 1992 - 10 - Evidently, this person liked to cross the Atlantic a lot: from NASA to France, from France to MIT, and from MIT to the Netherlands. The example in this section gives only a limited illustra- tion of the use of booby traps. Booby traps can be much more useful when installed on firewall systems [2], whose primary purpose is to separate an organizational network from the rest of the world. A typical firewall system provides only a limited collection of network services to the outer world, for example: telnet and smtp. By placing booby traps on the remaining network ports one can implement an effective early-warning system [1]. 8. Conclusions. The tcp wrapper is a simple but effective tool for monitor- ing and controlling network activity. Our FTP logs show that it has been installed in almost every part of the world, and that it is being picked up almost every day. To briefly recapitulate the essential features of the tool: o There is no need to modify existing software or confi- guration files. o The default configuration is such that the software can be installed "out of the box" on most UNIX implementa- tions. o No impact on legal users. o The wrapper program does not exchange any data with the network client or server process, so that the risk of software bugs is extremely small. o It is suitable for both TCP (connection oriented) and UDP (datagram) services that are covered by a central daemon process such as the inetd. o Protection against hosts that pretend to have someone elses name (name server spoofing). This is important for network services such as rsh and rlogin whose authentication scheme is based on host names. When a host name or address mismatch is detected the connec- tion is dropped even before the access-control files are consulted. o The optional access-control facility can be used to shield off open systems. Network routers can perform a similar function, but they seldom keep a record of unwanted traffic. On the other hand, network routers can be useful to block access to ports that normally cannot be covered with wrapper-like programs, such as July 15, 1992 - 11 - the portmapper, NIS, NFS and X server network ports. o The booby-trap facility can be used to implement early-warning systems. This can be especially useful for so-called firewall computer systems that only pro- vide a limited set of network services to the outer world. The remaining network ports can be turned into booby traps. Of course, the tcp wrapper is just one of the things I have set up on our systems: many other trip wires have been installed as well. Fortunately, I was able to do so before our present system administrator was installed. In any case, Dutch crackers seem to think that the systems at Eindhoven University are reasonably protected. 9. Availability. Several releases of the tcp wrapper source have featured in the USENET comp.sources.misc newsgroup. The most recent version is available from: ftp.uu.net:/comp.sources.misc/volumexx/log_tcp, cert.org:/pub/tools/tcp_wrappers/tcp_wrappers.*, ftp.win.tue.nl:/pub/security/log_tcp.shar.Z. 10. About the author. Wietse Zweitze Venema studied experimental nuclear physics at Groningen University. After finishing his Ph.D. disserta- tion on left-right symmetry in nuclear beta decay he joined the Mathematics and Computing Science department at the Eindhoven University of Technology, where he is now a con- sultant at the division of Operations Research, Statistics and Systems Theory. 11. References. [1] W.R. Cheswick, An Evening with Berferd, in Which a Cracker is Lured, Endured, and Studied. Proceedings of the Winter USENIX Conference (San Francisco), January 1992. [2] S. Carl-Mitchell, J.S. Quarterman, Building Internet Firewalls. UnixWorld, February 1992. July 15, 1992